1. Field of the Invention
The present invention relates in general to computers, and, more particularly, to a method of transparently recovering defective self-sustained code-upgrades.
2. Description of the Prior Art
Data storage systems are used to store information provided by one or more host computer systems. Such data storage systems receive requests to write information to a plurality of data storage devices and requests to retrieve information from that plurality of data storage devices. It is known in the art to configure the plurality of data storage devices into two or more storage arrays.
Associated with data storage systems, as with other computing systems, are firmware and software instructions to make the systems operational, the instructions being made up of a series of lines of system code. So-called “self-sustained” code-upgrade functionality allows for currently running code to perform one of two options. First, the currently running code can opt for the code's new version (e.g., the code-load “piece” within the about to be upgraded deliverable) to carry out an entire system code-upgrade function. Secondly, the currently running code can, when the new-code level is less functional than itself, continue the code-upgrade function by itself.
However, in the case that the current code is defective, to the extent that it always decides (because of the defect and/or bad code) to carry out the remainder of a code-upgrade function, new fixes can no longer be introduced into the code-load. The existing solution to such a problem is a human intervention of some kind, which is costly, slow, and is error-prone. Another approach includes a design which allows for some dormant, “only-for emergency” code to be incorporated into the initial design in a “just-in-case” approach. Again, such an approach is problematic, as the emergency code is normally not to be used and when needed might be proven to be also defective.
Including a pre-install type of facility which is called by the code-load code itself upon starting as a possible solution means that the code-load utility would run in its own environment. As such, the code-load utility would not be able to provide a simple, pinpoint fix to the defective code-load itself. Instead, the code-load code would be altogether replaced, which could be also counterproductive in certain applications. The use of pre-installation scripts could require that the pre-install segment would need to consult an elaborate table to decide what should be an appropriate replacement for the defective code coming from code-load, such that the code-load functionality would be able to be carried out in a successful manner. Additionally, a standard software bundle would necessarily include all of the previous code-load versions, which would incur additional cost and resource allocation.